13. File Systems

文件元数据(File Metadata)，也被称为文件属性(File Attributes)，包含对文件特征的描述信息，文件元数据并不作为文件数据，而是存储在文件系统的目录结构中。常见的文件属性有：

通过对文件的类型进行分类，文件可以被分为普通文件、目录文件、符号链接文件、特殊文件、套接字文件和管道文件。

文件类型是无穷多的，而操作系统并不能直接识别和解析所有类型的文件。虽然操作系统可以识别文件的基本类型（例如，通过文件扩展名或文件头信息），但要打开和正确显示特定类型的文件就需要安装相应的软件。典型的有Java的可执行字节流，这是一种二进制程序文件，但要是系统上没有安装 JVM，操作系统就无法直接运行这些Java字节码文件。

文件都是存放在磁盘上的，文件系统的职责是把各种各样的信息数据存放到非易失的存储介质上面。作为I/O设备，我们知道用户任何的请求都会转换成控制磁盘I/O的低级硬件指令交给I/O控制器处理。I/O控制层会收到basic file system layer的高级指令（如：read disk block 1），然后将其转换成磁盘能够理解的指令。又由于外设的低速性，我们对磁盘的操作一般是DMA的I/O控制方式。

具体来说，应用程序先是发出读文件的请求，这些请求经过层次转换到磁盘驱动程序将转换后的磁盘控制器命令交给CPU，然后CPU下达DMA控制操作，DMA控制器直接在内存和磁盘之间传输数据，而不需要CPU的持续干预。这种方式大大提高了数据传输效率，减少了CPU的负担。

基本文件系统负责与硬件交互，是文件系统中开始与硬盘硬件对接的层次。它会向磁盘驱动程序发布指定扇区的读写命令，之后由磁盘控制器驱动程序将命令传给磁盘控制器，控制器执行并返回结果，最终将结果交给操作系统。在这一层次中，对文件的操作是在物理磁盘上的，类似于磁盘1、12号柱面、7号磁道、1号扇区这样精确的磁盘访问请求就发生在这个层次。

由于磁盘访问的低速，在系统中实际上存在了许多buffers和caches来应对访问磁盘带来的开销。所以在这一层次，我们还需要考虑这些系统中存在的buffers和caches。只有当前要访问的数据不在这些buffers/caches中时，我们才需要考虑访问磁盘。也因此，我们需要承担突然断电时带来的数据丢失问题。

用户总希望自己的文件在系统中是连续存放的，正如我们之前学习虚拟存储技术时了解过的一样，即便我们看到的文件是连续的，但文件在磁盘上的存储块不一定是连续的。因此我们需要一个模块将逻辑块转换成底层硬件能够识别的物理块。

这种逻辑到物理上的转换就是由文件组织模块(File organization module)，也叫块管理器提供的。它是一个映射器(mapper)，将逻辑块地址映射成物理块地址。文件组织模块维护一个映射表，将文件的逻辑块转换为磁盘上的物理块地址，同时它也管理空闲空间列表，用于跟踪为分配的物理块。

除此，这一模块还负责空闲空间的管理，我们之后介绍。

对于用户而言，一个屏蔽底层硬件、简单、易操作的交互接口和能够对文件的属性进行方便管理的接口是ta们最想要的。而这个为用户提供方便接口的文件系统层次就由逻辑文件系统(Logical file system) 所提供。

逻辑文件系统负责管理文件的元数据。管理文件路径解析、文件描述符、权限检查等，并提供文件的操作接口（打开、创建、读和写）为用户使用，用户可以用系统调用（open/read/write等）与该层次交互。该层次也支持对文件的逻辑访问（逻辑上的文件）。

文件的元数据存放在一个叫文件控制块的东西里面，即FCB，在Unix中，文件控制块也叫inode。

在4. System Boots Up阶段中，我们谈到了计算机上电启动的一些内容。要使计算机正常启动，我们至少需要一块磁盘分区(volume)来存放操作系统的相关数据。我们谈到了磁盘分区上的第一个扇区，也叫启动扇区(boot sector)。当我们将视线放宽到整个volume，我们会看到：

在FAT的课程中，我们会结合FAT文件系统来进行介绍。

除了将一块磁盘一整块地使用，我们还可以逻辑上将磁盘分成若干个不同的区块来使用，这种方法也被称为磁盘分区。我们学习过 MBR 和 GPT 两种磁盘分区的方式。简单来说，磁盘分区就是在存储设备上创建一个或多个独立区域的过程，每个区域都可以作为独立的逻辑磁盘被管理使用。

为了管理这些不同的分区，我们需要一个分区表(partition table)，有时也被称为超级块(super block) 或 master file table。分区的相关信息就记录在分区表中，这些信息有开始和结束位置、分区类型和大小等。

在Windows中，磁盘分区常常与盘符相关联，每一个分区对应一个盘符（如 C: 、D:、E:等）。虽然一个物理磁盘可以分出多个盘符，但通常而言，一个物理磁盘我们当成一个分区使用。而在Linux系统中，磁盘通常会被分成多个分区，每个分区有不同的用途。例如，根分区（/）、引导分区（/boot）、交换分区（swap）等。

磁盘分区表的位置和大小会随着分区方式的不同而不同。我们学习过 MBR 和 GPT 两种分区模式。我们下面介绍这两种方式分区表存放位置。

主引导记录存放在磁盘的第一号扇区中，它包含了引导代码和分区表。MBR的大小通常为512字节，其中的bootloader占据446字节，分区表占据64字节。但如果系统采用 GPT 的分区方式，第一号扇区的大小就可能是 4KB 大小。

GPT(GUID Partition Table)：

当你对文件进行操作，你需要使用文件描述符(file descriptor)来对文件进行操作。在POSIX系统调用open()中，open()会返回给我们一个fd。而在C标准库中，我们会使用fopen()，其会返回一个指向FILE结构的指针。你可以用int fd = fileno(f);将FILE转换成fd。

以上是两种打开文件的形式，第一种使用C标准库，提供了一种更高级易用的接口，而底下我们使用POSIX系统调用，相比之下更为直接，但是不够user friendly。因为，用户并不知情FILE实际上是一个整数。我们之后会了解到，文件描述符是一个表示打开文件的整数。

以下是打开和关闭文件的POSIX系统调用原型函数：

以下是读写文件和移动文件指针的 POSIX 系统调用。

remove 函数和 unlink 函数在删除文件时的行为是相同的。当我们使用 remove 或 unlink 删除文件时，实际上是删除了文件系统中的一个硬链接。如果文件有多个硬链接，只有指定的那个链接会被删除，文件的内容仍然存在，直到所有的硬链接都被删除为止。

在第一节课，我们提到了文件的元数据，相当于文件的各种信息，这些信息被存储在文件控制块中。操作这些文件的创建修改删除是logical file system layer的工作。当我们要创建一个新的文件，对应着的，一个文件控制块也会随之被创建。系统内，每个文件的文件控制块都是唯一的。

当用户想要读取系统中的某个文件时，操作系统就会把文件的文件控制块加载进内存。由于文件控制块中有文件的元数据，所以系统可以根据文件控制块中文件在磁盘上的位置来加载文件信息。

Inode实际上就是类Unix系统中的文件控制块。我们将在后续ext文件系统的学习中进行介绍。

我们之前说，进程想要操作文件，就需要FCB中的信息。FCB载入内存需要我们使用open()系统调用，但之前，我们看到open系统调用返回的是fd，和FCB有什么关系？我们接着看。当进程打开文件时，OS就会在进程打开文件表里添加一个新表项。之后，操作系统会检查系统级打开文件表，如果没有找到关于该文件的表项，OS就会创建新的系统打开文件表项来跟踪文件的FCB。

进程打开文件表中存放着系统打开文件表表项的一个索引（fd），便于进程可以通过这个索引找到全局的系统打开文件表里面的表项，进一步对文件进行操作。进程打开文件表每个进程都有一张，每一个条目都对应着进程打开的文件和指向系统级打开文件表的指针，一般而言，进程打开文件表项数为1024，当然你可以将其设置的更高。include/linux/fdtable.h

当FCB加载到内存中后，系统用系统打开文件表对FCBs进行管理，系统打开文件表整个系统只有一张。系统打开文件表项的数据有文件名、文件打开方式、文件偏移量、文件的引用计数和FCB指针等信息。include/linux/fs.h

open文件调用会返回一个指向进程打开文件表中一个特定表项的索引，我们称其为文件描述符/文件句柄（unix中叫做file descriptor，而在windows中叫file handle）。

当进程要访问文件时，系统会根据文件的目录在磁盘上找到该文件的文件控制块。之后，将所需要的FCB都缓存在内核内存的FCB表/Inode表。然后系统在系统打开文件表中由相关的系统调用信息和FCB信息创建新的表项，其中有文件的一些元数据和一些其他信息。

当我们使用open("example.txt", O_RDONLY);时会发生以下情况：

在打开文件表中，除了文件的一些元数据外，还要存储文件引用计数信息，即这个文件被系统内的进程打开了多少次。每当使用open()或close()系统调用时，这个数值就会发生改变。只要不为0，该文件的元数据就会一直保留在内存的内核区中。

实际上，多个FD(file descriptor) 是可用指向相同的OFD(open file table descriptor)。像如下fd1和fd20都指向偏移为23的OFD（用dup2()复制文件描述符），还有两个进程的fd2都指向偏移为73的OFD（用fork()创建新的子进程）。

对于文件目录，文件系统需要支持关于目录的很多操作。最基础的就是用文件名来遍历查找文件，这是目录最基本的作用。此外，我们还想知道目录下有哪些文件，所以我们需要支持列出目录文件的功能。要查找文件，我们就得先创建文件，所以还需要支持文件的创建、删除和文件名的修改。

在命令行下，我们能见到很多目录相关的命令，例如：

文件的元数据存放在FCB中，文件系统通过FCB来实际控制管理一个文件；而目录是编排组织文件的表，通过目录中对相关文件的指针索引，实际上让我们得以访问对应文件的FCB，从而获取文件的详细信息并进行操作。文件目录以目录文件的形式存储在磁盘上，目录文件存储着系统目录的数据结构信息。

单级目录是最简单的目录结构，所有的文件都放在同一个根目录下。由于这种结构将所有文件放在一起，所以单级目录要求所有文件名必须是唯一的。这种结构是实现起来最简单的，但是文件的命名唯一而且对文件缺少归纳。导致这种目录管理文件就是一摊鸡毛。

在单级目录结构下，没有文件路径的概念。

在二级目录结构中，我们有一个主文件目录和子文件目录(sub-directories)。主文件目录可以向下级的用户文件目录提供索引。从而，每个用户可以拥有自己独立的目录来存储和管理文件。解决了一些单级目录中命名冲突问题，并为不同用户提供了文件隔离性。

从二级目录结构开始，文件路径有了意义，每个文件的文件路径(file pathname)在系统中都是唯一的。在引用文件时，如果确定当前的工作目录（用户目录），我们检索不包括用户名的文件时，操作系统会假设文件位于当前的工作目录下。这种不包含文件路径的路径名就是文件相对路径。

而绝对路径是指从根目录开始的完整路径，它包含了从根目录到目标文件或目录的所有目录名。例如，/user1/cat 就是一个绝对路径。无论当前工作目录是什么，通过绝对路径都可以唯一地定位到目标文件或目录。

在用户的目录下，用户无法创建新的目录来对文件进行进一步的归类。

树形目录是二级目录结构的升级版，树形结构目录允许子目录创建条目的子目录树，从而消除了文件不能归类的问题。整个目录树有一个根目录，所有的文件或目录都会有包含root的唯一路径名。树形结构为系统带来了更好的灵活性和可变性，在树型结构中，进程可以从一个目录下“跳跃”到另一个目录，也因而，相对目录通常上性能更好（减少了“跳跃”的动作）。在Linux下，我们用"."来指代当前目录（如./hello）。

上述的三种目录都不能够使得同一个文件/子目录在多个不同的目录下共享，用户访问其他用户的某些文件的愿望将无法得到满足。无环图目录允许一个文件/子目录同时存在于多个目录下，允许文件/子目录在用户多个间共享（不同目录访问同一个文件得到了实现）。

这种共享性有时候会用符号链接，也就是软连接实现，有时候也会通过硬链接实现。这两种不同的链接形式我们马上就会了解到。

在无环图目录结构中，目录不可以成”环“。然而这种环状目录在通用图目录结构中是允许的。环状目录或者成环其实就是目录中包含循环到起点的路径，即在下级目录中包含上级目录。

由于这种环状的存在，所以设计检索和遍历算法时就更加困难。这种环状可能导致遍历算法的无限循环，为了避免这种情况，设计者干脆禁止在目录中允许上级目录的存在。

AVL树(AVL Tree)是目录实现中常见的数据结构。

B树(B-Tree)极其变种也是目录实现中常见的数据结构。

在Linux中，我们用命令ln来创建一个硬链接，例如：

创建硬链接之后，两个文件会共享相同的inode（如上面例子中的Hello和Hard_Link）。也就是说它们会指向相同的数据内容。我们用stat命令查看Hello文件的元数据，可得：

我们看到，这两个文件名所指向的数据都是一样的。我们看到Links字段为2，这表示当前有两个目录项指向这个文件，也是文件的硬链接数。当硬链接数为0时，文件系统就会释放并回收文件资源。

我们用ln -s命令来创建一个软链接：

当软链接创建好后，软链接文件和源文件的inode并不相同。软链接本身是一个独立的文件，存储对源文件的路径引用。文件大小就是字符串的长度。我们用ls查看Soft_Link的大小，大小为5字节，正好是Hello文件名的长度。这里引用的是相对路径，但也可以引用绝对路径。

当源文件被删除，软链接就会指向一个不存在的路径。这时，软链接会变为无效链接，这就是“断链”现象。

我们看到的文件（即逻辑上的文件）主要有两种访问方式：顺序访问和随机访问（直接访问）。还有其他的访问方式都是在这两种访问方式的基础上建立的。

我们前面提到了四种文件结构，对于这四种不太文件结构的文件而言，它们会遵循不同的访问方式。对于线性顺序结构的文件来说，由于要读取访问下一个字符数据必须先访问上一个字符数据。所以文件的访问必须是连续的，这不难理解。

对于索引结构的文件来说，索引表可以让我们访问文件的不同位置。然而，通过索引表跳转之后，文件的访问转而变成线性顺序的访问（宏观上跳转，微观上连续）。类似的，由于层次化的结构相当于多级索引，我们可以跳转到我们想要数据的最小目录下访问，这个访问是线性连续的。

对于分段结构的文件，我们可以将其理解成类索引的顺序结构文件。在 ELF 中，我们将文件中不同的内容划分到各个节中，这些段相当于独立的线性顺序结构的文件，但我们通过节头表定义并索引了文件中各个节的位置及属性。在 ELF 文件中，文件访问同样是节外跳转、节内连续。

连续分配就是指文件占用一组连续的磁盘块。逻辑上相连的块在物理上也相邻。所以这种分配方式带来的好处就是当磁头读到的文件位于磁盘块b时，读取下一个文件块b+1时，磁头并不需要怎么移动，也就不存在寻道时间了（最小的寻道时间）。在这种分配方式下，磁盘的目录项包括：

即你只需要两个参数（起始块地址和文件长度）就能够keep track of this file。如果你需要读取 b+n 磁盘块中的内容，你只需要将磁头移动到相应的位置上，而不需要顺序一格一格地移动磁头，算是一种随机存取。这种方式可以轻易地实现对文件的顺序和直接访问。

而且这种方式在检查文件访问是否有效时非常简单，假设文件长度是 n，文件的起始块地址是 b。如果访问的磁盘块地址> b + n，那么就可以断定这个访问是不合法的。

享受完顺序分配给我们带来的简单性，我们就需要来承担相应的缺点。在顺序分配方式中，我们如果有一个大小为 N 个磁盘块的文件，在存储这个文件时，我们需要考虑：

在磁盘空间动态分配时也可以选用不同的分配策略（首次适应、最佳适应、最差适应）。显而易见的是，这种分配方式会造成不可避免的外部碎片(external fragmentation)，内部碎片(internal fragmentation)由于被控制在一个块的大小内，所以我们不需要注意。在这种分配方式下，如果文件很大，所有孔的容纳不下，那么文件将无法载入磁盘。

好，既然我们不确定文件有多大，也不想任何外部碎片的产生，我们为何不将文件块链式地存放在磁盘上呢？将文件进行分割成块，分配在多个离散的磁盘块中，通过指针连接。不会产生任何的外部碎片，而且文件扩展较为容易。如何？

顺序分配和链式分配的关系相当于数组和链表之间的关系。链式分配带来了诸多好处，其中最主要的就是避免了任何的外部碎片。但是由于需要指向下一个磁盘块的指针和不能随机访问的特性，使得链式分配方式会不可避免地占用一点空间用于存储指针，并且速度慢（存在寻道时间）。

链式分配方式的一大缺点就是当你要找一个文件块，你就必须得顺着指针链条往上找。所以一般的实现上，通常会结合连续分配和链式分配的优点。即以簇(clusters) 为单位进行连续分配，我们可以设置为4个块1个簇，然后将这些单位链接起来。这种方法可以提高访问速度，同时减少碎片问题。

如果你是原始链式分配的原教旨主义者，你就会将自己困在无法随机访问带来的访问速度的困境中。然而，我们可以给每个文件建立索引表，把所有的指针都顺序地放在一个磁盘块中，记录文件各逻辑块对应的物理块。这样就可以实现随机访问文件了，吸收了顺序分配的优点；而且不会产生任何的外部碎片，同样结合了链式分配的优点。

这种分配方式真不错，既保留了顺序连续分配的优点，也保留了链式分配的优点。但是有一点不足，即当文件变得很大，我们就没有办法对文件进行分配了，因为一个块能够索引的大小很有限。对于这种窘境，人们想出来很多办法。如：将index block最后一个index entry作为下一个index block的entry（linked scheme）；加入上级的index对index block进行索引（multilevel index）；将上述的方法结合起来，这也是inode所使用的方式（combined scheme）。

下图展示了unix inode的multilevel indexing，在本阶段后续的课程中我们会详细介绍。

FAT文件系统下，磁盘结构被划分成引导扇区、文件分配表FAT、根目录区和数据区域。我们接下来逐步介绍。

我们常常会看到FAT16/FAT32，FAT后面的数字代表什么呢？这代表着FAT表中表项的位数，即FAT能够寻址的簇数。通过这个信息和簇大小信息，我们就可以得到最大分区大小是多大了。文件大小根据目录表项（FCB）中文件大小字段的位数决定。

在ext2文件系统中，磁盘空间被划分为连续的逻辑块(blocks)。块大小并不需要与磁盘的物理扇区大小相同，因此块的大小还能更大，以便优化文件系统的性能和数据管理效率。在ext文件系统中，超级块负责卷空间信息的记录和管理。块大小由超级块中特定的字段所设置。

块大小一般会设置为是1024字节、2048字节或4096字节（ext2中块最大可以设置为65536个字节）。一旦文件系统初始化完成，块大小就将固定。块大小越小，存储文件产生的存储碎片就越少，但是相应地就会带来额外的管理开销（而且文件大小和文件系统大小就越小）。当前，主流的默认块大小是4KB。

块组是许多个块聚合在一起所构成的。磁盘空间被划分成了若干个块组，这样组织有效的避免了文件分散在磁盘的各个位置，从而减小了磁头的寻道时间；同时，也对碎片化有重要的影响。除此之外，块组中包含有一些重要数据的备份（如超级块等），使得文件系统能够在必要的时刻重建。

磁盘被划分为若干个块组。每个块组由一定数量的块(Blocks)构成，包含：超级区块(Super Block)、组描述符表(Group Descriptor Table)、区块位图(Block Bitmap)、索引节点位图(Inode Bitmap)、索引节点表(Inode Table)、数据块区(Data Blocks)。

当一个文件的数据量超过一个块组的容量时，文件的数据块会分布在多个块组中。inode中的块指针可以指向不同块组中的数据块，从而实现跨块组的存储。一般而言，块组描述符表还会有一个备份，一个标准的块组0磁盘布局如下（N>>n）：

ext2文件系统所有核心配置信息都存储在超级块中，它包含了如文件系统中的inode总数、块总数、块大小、空闲块和空闲inode数量等信息，对于文件系统的正常运行和管理至关重要。超级块位于卷偏移1024字节后（boot loader之后），由于超级块的重要性，在最初的ext2版本中，每个块组中都会留有超级块的备份。之后的版本将组号为0、1还有奇数的平方作为超级块的备份块组使用。

ext2文件系统的超级块以小端方式存放在磁盘上，所以文件系统在不同机器上是可移植的。

Inode是ext2文件系统中的一个重要概念。Inode本质上是文件控制块，任何在ext2文件系统上的对象都需要用inode来表示，如文件、目录、符号链接等。inode中包含着除了文件名以外的所有文件元数据，如文件的权限(permissions)、所有者、组、flags、大小、使用的块数、访问创建修改删除时间、链接数、ACLs等。

每个块组都有一个线性数组来存储inode节点数据，这个数组被称为 inode table。在ext2/3中，每个inode需要128KB的存储。每个inode都属于一个特定的块组，并存储在相应的 inode table 中。

在ext2文件系统中，目录也是以文件的形式存储在磁盘上的，目录文件的文件控制块（FCB）也是一个inode。在目录文件中包括许多目录项(Entry)，文件名和其inode编号就存放在目录项中，通过这一对文件信息可以检索到某一个文件。这些目录项使得操作系统可以通过文件名查找到对于文件的inode，进而访问文件的元数据和实际内容。目录项包含以下内容：

其中文件类型有以下几种：

ext2文件系统用单链表来存储目录中的文件名；在改进后的版本中，使用文件名的哈希值来进行查找，免去了对整个文件目录的扫描。

POSIX有个系统调用flock()，我们可以用它来对文件进行加锁。下面实现了一个对文件的互斥锁（一个写锁）。flock()有两个字段，第二个属性字段除了LOCK_EX之外，还有LOCK_SH用于设置一个共享的锁、LOCK_UN对锁进行解锁。

flock()的函数原型如下：

这种写锁（LOCK_EX）只允许一个进程访问文件，对整个文件都进行了加锁。如此，其他进程不能读写该文件，如果我们想要对文件进行粒度更细的管理怎么办？我们可以使用POSIX提供的fctnl系统调用。

fcntl() 提供了更复杂和灵活的文件锁定机制，支持对文件的部分区域进行锁定。通常情况下，部分锁定(partial locking)也会被称为记录锁定(record locking)。我们常常在data record中看到这种记录锁定。我们现在其实并不怎么使用这种部分锁定，因为有数据库在背后帮我们处理这些事情。

通过将文件划分成多个部分，例如6个部分，我们最多可以同时有6个程序对文件进行读写操作。fcntl()是一个强大的系统调用，命令字段实际上有很多参数信息。我们在这里只讨论关于文件锁的部分信息。以下是 fcntl() 的原型：

如果你不想让文件锁定操作那样复杂，那你可以使用lockf系统调用。在一些系统上，lockf是由fcntl系统调用封装而来的，但有的系统可能使用其他的机制。所以当你lock a file时，确保使用同样的系统调用来lock and unlock，避免可能出现的一些未定义行为。

mandatory locks do exist,but are hard to use and not recommended

除了上述我们学习过的这些文件锁，我们可以用文件来控制文件的并发访问。将一个文件的存在当作一把锁，如果文件存在，则说明区域已被锁定。Git会通过在特定的目录处放置一个index.lock的文件来指示进行中的操作。通过这个文件，git就能避免多个git客户端同时操作一个repo。

为了实现这种机制，我们可以使用以下的系统调用：

open系统调用有许多选项，在这种情形下，我们并不想使用”如果文件存在，则打开文件“的open系统调用。我们想要系统告诉我们：”如果文件存在，则创建失败并返回错误码“。所以我们要用O_CREAT和O_EXCL这两个flags。前者是创建文件，后者是exclusive的缩写，当两个一起使用时，就会在文件存时返回失败并设置errno为EEXIST。

用于open系统调用是原子化的，所以实际上避免了多个进程的并发问题。在操作完成后，我们用remove系统调用来删除文件，让下一个用户进程对文件或repo进行操作。

那rename系统调用是做什么的？rename系统调用和open一样，也是原子化的。这样，我们其实可以单单用rename来进行lock和unlock操作。改名就是锁定，解锁呢，就是将文件名改回来。

Lock-Modify-Unlock常会用在集中式的版本控制系统中。在开发者修改文件之前，首先锁定文件，防止其他人同时修改（lock）；之后，开发者对文件进行修改（modify）；完成后解锁文件，运行其他人对文件进行修改（unlock）。以下是我们用文件作为锁对这种方式的简单实现：

这种方法确保了在修改期间没有其他人可以修改同一个文件，从而避免了冲突。然而，它也可能导致开发效率降低，因为其他开发者在等待锁释放时无法进行修改。

而在分布式版本控制系统，如git中，有了分支的概念。多个开发者可以把代码从远程仓库复制到本地，每个开发者可以在自己的分支上独立开发，并行工作（copy-modify）；修改完成后，开发者可以将自己的分支合并到主分支，git会自动处理大部分的合并（merge）。

对文件的这些修改会被记录到项目的提交记录中。如果两个分支修改了同一文件的同一部分，那么这些修改将不会被自动合并，我们称之为冲突（conflict）。如果出现冲突，合并操作将暂停，直到冲突被手动解决。

为了避免不连续性，合并操作要么成功，要么失败，这是由事务机制实现的。事务(transaction) 相当于要一气呵成完成的一组操作，一个事务有两个开始事务和结束事务两个状态。在merge的过程中，对合并文件的一些检查会用一个log记录下来来进行检查，对事务的检查是不可中断的，如果发生冲突那么合并就会失败并回退到之前的状态（roll-back）并等待开发者的手动解决。

实际上，inotify应当被单拎出来。inotify是内核为我们提供的监视文件系统是否有事件发生的工具，它可以监控文件或目录的各种事件，如创建、删除、修改等。它本身并不是一个并发控制的工具，但一些情况下，inotify可以在并发控制中起到一些辅助的作用。

利用inotify API，你可以让你的程序对一些事件做出反应，比方说当某个文件被打开，程序做出一些响应。要让inotify给你发消息，你需要遵循以下步骤：

值得注意的是，这个过程不是递归的。

我们有以下系统调用，初始化inotify的系统调用很好理解，即初始化创建一个inotify实例，一旦实例被创建，内核就会设置必要的数据结构和资源来管理inotify子系统。

实例创建完之后，我们就要用inotify_add_watch()来指定你想要以监视的文件或目录。系统调用inotify_add_watch()会返回一个监视描述符，用于唯一标识的监视项（文件）。另一个系统调用inotify_rm_watch()是将特定的wd从inotify instance中删去。

之后你可以read(fd, buf, size)，阻塞直到相应的事件发生。当你要监视的事件发生，inotify会将事件信息填充到 inotify_event 结构体中，并通过初始化得到的文件描述符返回给你。

由于最有一个字段是可选的，因而inotify_event结构体大小为：

由于长度是不确定的，由此我们想要设置缓冲区时可能会设置的过大或过小。在设置缓冲区之前，我们可以用ioctl(inotify_fd, FIONREAD, &numbytes)先获取文件当前可读取的长度。但一般情况下，我们会用空间换时间。

那么，什么是不连续状态？文件不连续后操作系统会如何反应？我们提到了系统掉电而文件没有来得及写回磁盘的情况。当系统重新上电后，我们会发现一部分文件块由于掉电时在内存中而遗失掉了，这就是文件的不连续状态。不连续的文件可能会导致一些严重的问题。

例如，我们本来要创建一个大小10个块的文件，在FCB中文件大小字段中就将其标识为10个磁盘块。然而，之后的文件链表中只包含有5个块。当使用这些系统调用工具检查出不连续状态时，我们希望系统能够把遗失的块找回来并链在一起，但文件系统可能并不能这么做，文件系统会修改相关的信息（如FCB的文件大小字段修改为5），从而保证文件的连续性。

系统视角下的recovery和我们想象中的recovery好像并不太一样，但不论怎样，现在文件是连续的了，系统内没有错误了。任务完成！

我们当然希望避免不连续问题的发生，以防因此出现严重的系统故障。避免因一些错误导致的数据不连续，你可能会想到原子操作。实际上，我们要使用避免数据不连续的方法事务其实我们可以看作原子操作的一种变种。事务使得操作要么完美地完成，要么就什么都不做。当今几乎所有的文件系统都会使用事务来避免data inconsistency的发生。

在版本控制系统和数据库中，为了使每个版本的数据都是连续的，这些软件会在修改文件相关结构之前，先列出一个待办事项清单。当这个待办事项清单中的所有待做项都完成之后，我们才会认为这个事务结束了，系统随之修改相关的数据结构。

ZFS使用single-atomic-update的事务机制来避免磁盘上的不连续性，这种机制类似于copy-modify-merge模型。数据先是从磁盘拷贝到内存，之后修改拷贝的磁盘块，最后将拷贝写回磁盘。这些修改后的新数据写回磁盘是并不会覆盖原旧数据块，而是将拷贝写到新磁盘块。这样其实为操作提供了冗余，如果写磁盘不连续，我们可以抛弃写回的数据块（即什么也不做）。如果操作一切顺利，那么我们就可以将旧磁盘块的引用用新的磁盘块所替代。

如果磁盘空间满了怎么办呢？那就买一块更大的后备硬盘吧！

在NTFS中，所有对文件元数据的修改都会顺序地放到一个日志文件(log文件)中，一旦修改写入日志文件后，系统才会实际修改文件的元数据。这种机制被称为日志记录(journaling)。当系统修改完文件的元数据后，系统会将日志文件中标记为“已完成”的日志记录（事务）进行相应的清理。

之后，当系统崩溃，日志文件中就可能包括0个或多个事务待处理。0个当然最好，你不需要担心任何事；如果届时日志文件中有多个事务还没有处理，就意味着仍有事务没有完成。我们将有两种解决方案：前进和回退。

在NTFS中，日志记录的实现如下：